Date: Mon, 15 Aug 94 04:30:17 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #272 To: Ham-Digital Ham-Digital Digest Mon, 15 Aug 94 Volume 94 : Issue 272 Today's Topics: Help with info Need mods to do FSK on Alinco DR-600 Packet BBSs for Unix? Packet Node Info Wanted PK-88 to Kenwood TM-231A interface simptr21.zip - Generic TNC comm program (packet, rtty, etc) Smallest MultiMode TNC? TAPR FTP SITE??? Widrow-Hoff LMS algorithm for DSP??? (2 msgs) Windows 3.1 and Baycom Modem TCP/IP networking Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sat, 13 Aug 1994 17:54:00 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!iat.holonet.net!bthouse!mike.grose@network.ucsd.edu Subject: Help with info To: ham-digital@ucsd.edu MS>From: mike@jakesys.sol.net (Mike Sheridan) >Newsgroups: rec.radio.amateur.digital.misc >Subject: Help with info >Date: Sat, 6 Aug 1994 06:54:32 GMT >Message-ID: <1994Aug6.065432.1392@jakesys.sol.net> >Organization: jakesys - Public Access UNIX - Manitowoc, WI MS>Can anyone steer me into info on how to get started with packet radio >with a 486 clone? >--- Hello Mike. You have the main thing needed for packet radio. Just get you a tnc(terminal node controller) and a two meter radio. a Handy talkie works well, or you can use a mobile rig. Most use HT's because they are less expensive used. You need to get software for packet. If you use Procom, it will work very good. You just set it up in the dumb terminal mode. Then get the manual out for your tnc, and start programing the commands you will need for packet. There are many programs out there, but I would suggest using a dumb terminal for a while to learn the commands and kind of get familiar with it. I use a Tandy 486 machine, and it works very well. You don't have to have too much to run packet, as it doesn't take much memory to run it. If you have anymore questions, please let me know. Cul....Mike, KE4CLE * QMPro 1.50 42-2694 * All rising to a great place is by a winding stair. ------------------------------ Date: 13 Aug 94 08:00:00 GMT From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!gatech!wa4mei!totrbbs!steve.diggs@network.ucsd.edu Subject: Need mods to do FSK on Alinco DR-600 To: ham-digital@ucsd.edu Hi Rob, ftp to oak.oakland.edu and look in /pub/hamradio/mods/alinco. If it isn't there message back to me and I'll look in my my mod file collection. Regards, Steve Diggs ---- Top Of The Rock BBS - Lilburn, GA SYSOP: Steve Diggs UUCP: totrbbs.atl.ga.us Snailmail: 4181 Wash Lee Ct. Phone: +1 404 921 8687 Lilburn, GA 30247-7407 ------------------------------ Date: Fri, 12 Aug 1994 03:00:27 GMT From: ihnp4.ucsd.edu!usc!cs.utexas.edu!convex!news.duke.edu!eff!news.kei.com!ssd.intel.com!chnews!ornews.intel.com!ibeam!knauer@network.ucsd.edu Subject: Packet BBSs for Unix? To: ham-digital@ucsd.edu Greetings all. I'm relatively new to the packet scene, so if this is an obvious question, please forgive. What I'd like to find is code for a packet BBS that will work on a Unix box (specifically, SunOS on a Sun 3/60). Provision for either BBS operation or direct login (sort of a packet getty) would be fine; from that point I could hack the source either way. Does such a creature exist? If not, do any of the common BBSs for the PC (W0RLI, etc.) come with source? I'd like to avoid starting from scratch if at all possible. [The next obvious question is if there already exists a packet->UUCP gateway, but I'll save that for when I have spent more time goofing around with packet in general...] Thanks, Rob -- Rob Knauerhase [knauer@ibeam.intel.com] Intel Mobile & Home Architecture Lab "Always listen to experts. They'll tell you what can't be done, and why. Then do it." -- Robert Heinlein (Lazarus Long) ------------------------------ Date: Thu, 11 Aug 1994 14:40:25 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!jsissom.dmed.iupui.edu!JAY@network.ucsd.edu Subject: Packet Node Info Wanted To: ham-digital@ucsd.edu Interesting, an Amateur Radio mode where DXing is discouraged! This is a new one. . . I agree that people should use their closest BBS, but there shouldn't be any problems with people node hopping to see how far they can get! Experimenting is what ham radio is all about, isn't it? Jay >::Arrrgh! You're a digi Dxer, the bane of network existance. :-); >:: >:;Really, we've spent a lot of time educating our users to stay on >:;their LAN and let the network do the forwarding. All it takes is >::a couple of digi Dxers accessing a distant BBS to bring a 1200 baud >:;trunk to it's knees from retries and collisions. ------------------------------ Date: Thu, 11 Aug 1994 14:44:42 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!jsissom.dmed.iupui.edu!JAY@network.ucsd.edu Subject: PK-88 to Kenwood TM-231A interface To: ham-digital@ucsd.edu Last night, I built a cable to connect my PK-88 to my TM-231A. I don't have the pin out here, but it was quite simple. Unfortunately, the DCD lite on the PK-88 stays on when the radio is squelched. Because of this, the PK-88 will never tell the radio to transmit. It receives fine. If I am tuned to a repeater and there is no sound coming through the repeater, then the DCD lite is off. I'm kind of confused. This PK-88 has been hooked up to my Icon IC-28H for years with no problems. Has anyone else seen this problem, and solved it? Thanks Jay KA9OKT jay@medicine.dmed.iupui.edu ------------------------------ Date: Sun, 14 Aug 1994 14:17:57 GMT From: ihnp4.ucsd.edu!agate!spool.mu.edu!nigel.msen.com!simtel.coast.net!msdos-ann-request@network.ucsd.edu Subject: simptr21.zip - Generic TNC comm program (packet, rtty, etc) To: ham-digital@ucsd.edu I have uploaded to the SimTel Software Repository (available by anonymous ftp from the primary mirror site OAK.Oakland.Edu and its mirrors): SimTel/msdos/hamradio/ simptr21.zip Generic TNC comm program (packet, rtty, etc) SimpTerm v2.1 is a simple terminal program designed to be used with almost any tnc or tu on the market. Features of SimpTerm are: o Split window operation. o Macro key definitions. o User customizable Help screen o Most of the non-ascii keys can be used as function keys o Optional scroll back feature on the receive window and trans- mit windows o Simple status display in the middle of the screen o Capturing of data to a disk file o Access DOS commands without dropping communications connection o Control of the com port definitions from command line, init file and keyboard. o Works on 8088 as well as 80486 and everything in-between. o Status line o Small enough to work well on resource tight platforms, like laptops. o Selcal functions, limited unattended operation. o Times can be in GMT or local time. o A station logging function. o User selectable color scheme o Automatic "cq" operation (or any other repetitive transmission o Function keys and control keys can be assigned to a macro string, cause a file to be uploaded or call a function within the program. There are loads of programs that are tailored to specific tnc's and there are dozens of good terminal programs that can control any tnc in a "dumb" (that's a technical term) manner. This program is an attempt to provide the average ham with something in-between. It has a lot of features, but not so many as to make use of the program or the tnc hard. It requires you to know the commands of your tnc, but also gives you the flexibility that only direct communications with a tnc can provide. Jim Lynch, K4GVO jwl@cray.com ------------------------------ Date: Fri, 12 Aug 1994 09:51:32 -0400 From: ihnp4.ucsd.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!news.clark.edu!netnews.nwnet.net!raven.alaska.edu!news.acns.nwu.edu!ftpbox!mothost!lmpsbbs!NewsWatcher!user@network.UCSD Subject: Smallest MultiMode TNC? To: ham-digital@ucsd.edu In article , newmedia@teleport.com (Jim Swenson) wrote: > Please help me find the smallest multi mode TNC available. I am provisioning > a 40' sailboat for a ham friend for a several year cruise. Space is at an > absolute premium. He'll be operating exclusively HF through a modified ICOM > M600 SSB marine transceiver. So 300 baud max is fine. Required modes include > Packet, WeFAX, NAVTEX, RTTY, CW. PACTOR, G-TOR and SITOR would be cool but > not mandatory. Cost is a secondary consideration. The size of most units > I've looked at are just not acceptable. Ideally, we need something about the > size of a new Supra modem (about 1" h by 5"w by 7" deep). Is there such > a beast. I'd appreciate any help. Although I can't directly answer your query, I'll take the time to point out something that you must consider: Most commercial/marine HF transceivers will NOT accept the standard "high" tones 2110/2310 used by the amateur community due to the required audio rolloffs when operating in a 2.5 kHz channelized environment. Check to see if the M600 has a "direct FSK" capability so that you can run with TTL or RS232 connection to the TNC instead of audio. That is by far the preferred method and eliminates problems with AC hum, alternator whine, or ignition spikes on the interconnecting cables. If you can't run DFSK, be ABSOLUTELY sure that the multi-mode unit you purchase offers FSK tones in the 1200-1800 Hz range or you will have MAJOR problems. I don't have the CCIR or CCITT list of worldwide standard tones handy, but I recall 1300/1500 and 1410/1590 both being common. In any case, you get the point, especially if your friend's life might depend on this comm gear at some point. We all want him back alive, especially if he will be rare DX during the trip!! -- Karl Beckman, P.E. < If our English language is so > Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > (Square waves & round corners) < parkway and park on the driveway? > Opinions expressed here do not belong to or represent Motorola Inc. Amateur radio WA8NVW NavyMARS NNN0VBH @ NOGBN.NOASI ------------------------------ Date: 14 Aug 1994 13:43:24 GMT From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!lll-winken.llnl.gov!noc.near.net!news2.near.net!news.umass.edu!nic.umass.edu!twain.ucs.umass.edu!mwarchut@network. Subject: TAPR FTP SITE??? To: ham-digital@ucsd.edu Does anyone know the ftp site for TAPR. -- *---------------------------------------------------* | Michael W. Warchut Voice: 413-545-2036 | | Senior Technician Fax : 413-545-2418 | | PC Maintenance Lab I am only 100% right, | | University of Mass 50% of the time. | *---------------------------------------------------* ------------------------------ Date: Sun, 14 Aug 1994 07:15:06 GMT From: ihnp4.ucsd.edu!agate!library.ucla.edu!news.ucdavis.edu!news!schenck@network.ucsd.edu Subject: Widrow-Hoff LMS algorithm for DSP??? To: ham-digital@ucsd.edu In article ahall@ux4.cso.uiuc.edu (Allen Hall) writes: Hello again everyone, I was wondering if you knew anything about the Widrow-Hoff LMS algorithm that was used in Sept. 1992 QST's article "Low-Cost Digital Signal Processing for the Radio Amateur". Appearantly the LMS algorithm is nice to use to cut out signals that are repetetive when listening to SSB (you wouldn't use it for CW- cause all you would hear instead of the morse code was a "click" evertime a new tone came buy :) Appearantly this algorithm is used in the HumVee's to stop engine noise in the cabin. (I think there are other car companies working with it to reduce second-order boom in 4 cylinder cars). If you know where I can find this algorithm or further information about it, please let me know. TNX et 73! Allen Hall n9rzc@uiuc.edu ps- as always, I look forward to any and all comments that you may have concerning this posting. Details of the LMS algorithm can be found in virtually any introductory book or paper on adaptive signal processing, e.g., _Adaptive Signal Processing_ by Widrow and Stearns or _Adaptive Filter Theory_ (or something like that) by Simon Haykin. The basic algorithm is as follows: X(k) is an N-element array of input samples at time k. For a transversal filter, the elements of X are samples in a shift register. W(k) is an N-element weight vector (i.e., the filter coefficients) at time k. Ideally, when the adaptive filter converges, W() will change slowly or not at all with time. d(k) is the desired signal at time k. How this desired signal is generated depends on the application. It can be merely correlated with the actual signal. We define the instantaneous error as e(k) = d(k) - X(k)^T W(k), where ^T denotes matrix transpose. LMS is a form of the steepest descent algorithm dating back to Cauchy (or some other famous dead guy), where the gradient of the mean squared error (MSE) with respect to the weight vector is used adjust the weights so as to minimize the MSE. The trick behind the LMS algorithm is to replace the MSE with the instantaneous squared error in the computation of the gradient. Skipping the math (which is actually fairly simple), we get W(k+1) = W(k) + mu e(k) X(k) Simple as that. mu is called the adaptation step size. If it is much too large, the filter becomes unstable and never converges. If it is a bit too large, the MSE will not reach its minimum value. If it is too small, the filter will take forever and a day to converge. A rough first guess for setting mu for a transversal filter is mu = 1 / (N * signal power). Ideally, it should be relatively large at first and then made smaller when the filter nears convergence. As you can see, it's a simple algorithm to implement, which is why it's so popular. It can be slow to converge, however, depending on the error surface and the initial weight vector. Also, because it never (or almost never) actually reaches the minimum MSE, the LMS name is not quite acurate; some people prefer "stochastic gradient" algorithm. But since it's so simple, it's easy to simulate and play around with on a computer. Have fun. -- Jeff Schenck schenck@ece.ucdavis.edu Department of Electrical and Computer Engineering __o University of California _`\<,_ Davis, CA 95616 (_)/ (_) (916) 752-1326 ~~~~~~~~~~~~~~~ ------------------------------ Date: 13 Aug 1994 13:15:57 -0700 From: nntp.crl.com!crl3.crl.com!not-for-mail@decwrl.dec.com Subject: Widrow-Hoff LMS algorithm for DSP??? To: ham-digital@ucsd.edu Allen Hall (ahall@ux4.cso.uiuc.edu) wrote: : Hello again everyone, : I was wondering if you knew anything about the Widrow-Hoff LMS algorithm : that was used in Sept. 1992 QST's article "Low-Cost Digital Signal : Processing for the Radio Amateur". Appearantly the LMS algorithm is nice : to use to cut out signals that are repetetive when listening to SSB (you : wouldn't use it for CW- cause all you would hear instead of the morse code : was a "click" evertime a new tone came buy :) : ... etc ... The Widrow LMS and Wiener-Hopf are adaptive digital filtering techniques. The following books have chapters on adaptive digital filters: 1. Digital Signal Processing - A practical Approach Emmanuel C. Ifeachor and Barrie W. Jervis 2. The TI Digital Signal Processing Applications Series: Applications with the TMS320 family, algorithms and implementation Vol 1 part number is SPRA012A Vol 2 part number is SPRA016 Vol 3 part number is SPRA017 This series of books deal exclusivly with the TI DSP processors. There is a lot of practical applications as well as some theory. The TI literature number is 1-800-477-8924, all they need is the part numbers and your address, the books are free. -- Henry Smith (hbs@crl.com) ------------------------------ Date: Sun, 14 Aug 1994 01:53:33 GMT From: agate!spool.mu.edu!uwm.edu!news.alpha.net!mvb.saic.com!eskimo!rdonnell@ames.arpa Subject: Windows 3.1 and Baycom Modem TCP/IP networking To: ham-digital@ucsd.edu Andrew J Lynch (ei938@cleveland.Freenet.Edu) wrote: : Packet Radio Folks, : I have a question regarding Windows 3.1 or WFW and ham/packet radio: Is there a Windows or WFW driver available for the Baycom packt radio modem that would allow TCP/IP networking functions over packet radio? : I understand that Windows 3.1 or WFW can use TCP/IP networking with the WINSOCK.DLL. This provides TCP/IP networking services to an Windows TCP/IP application. Whatever networking medium used requires a driver, ie SLIP/PPP, ethernet, token ring, etc. : Ham/packet radio also uses TCP/IP as a protocol in local area networks. I have a Baycom modem and plan to use the AX.25 driver withthe DOS program KA9Q NOS to access the local TCP/IP packet network. : My question is: Is there a way to tie the Baycom modem into Windows 3.1 or WFW? You could then use the TCP/IP applications over pacet radio just like you would over an ethernet or SLIP/PPP, only much slower. I think you would need a packet driver like the etherne cards require. : Has anyone got any information on this? If I get any responses, I will combine and post to this list. : THANKS IN ADVANCE!! : Andrew Lynch, N8VEM : alynch@wpgate1.wpafb.af.mil : 73!! You're probably not going to have a lot of luck doing this with Windows and the Baycom. The Baycom product requires a lot of the computer's attention, because it has to 'bit-bang' data into and out of the serial port. It can't take advantage of the parallel-to-serial/serial-to-parallel conversion capabilities of the serial port, and therefor is very processor-intensive. This along with Windows being intensive and trying to multi-task is not a good combination. There are folks who are working on writing a packet driver to go between Windows TCP/IP applications (Winsock or FTP's PACKET driver interface) and a KISS-capable TNC. But I don't think you're going to see it for Baycom-type modems. Think of it this way - Most Windows systems have trouble keeping up with 19200 baud with only one task open when you don't use a buffered UART. All the application has to do is get the interupt, read the port, clear the port, then display (or process) the byte received. At 19200 baud this happens at 1920 times per second or slower, and you have until the next charachter has arrived to read the currently stored character before you will lose data. Also, typically the most intensive processing that has to be done on a character-by-character basis is CRC calculations. When sending characters, all the program has to do is respond to keyboard interupts (if typing), send bytes to the com port, and wait for an interupt from the com port that says it's ready for another byte, and perhaps update CRC calculation. With Baycom, assuming the software is set up to use one of the PC's timers (the lowest processor overhead), at 1200 bauds, when the interupt comes in, you have to go read the timer, reset the timer, decide how many bit times have passed since the last interupt, stuff and shuffle the proper number of bits into the shift register, account for 'bit stuffing', then see if you've filled a byte. If so, the byte goes into the packet buffer, and if you have time, maybe you update the CRC calculation for the packet. This can happen in one bit-time (1/1200th of a second, more or less, depending on signal 'twist' and modem timing errors). And all that processing has to be finished before the next interupt. Then when a packet is complete and error-free, the driver still has to check addressing, etc. all of this is >before< the packet gets passed up to the TCP/IP software stack. And the driver has to continue handling interupts and dealing with the incoming data stream, trying to make sense of it accurately, until the data stream stops - usually when the squelch on the radio closes. And during all this, Windows is supposed to find time for other applications to run. Not a problem that will be easily solved. 73, Bob -- --------------------------------------------------------------------------- Bob Donnell, kd7nm bob@ethanac.kd7nm.ampr.org rdonnell@eskimo.com Western Washington Amateur IP Address Coordinator (206) 775-3651 --------------------------------------------------------------------------- ------------------------------ End of Ham-Digital Digest V94 #272 ******************************